Application No. 10/775,488 

Amendment dated January 8, 2007 

Reply to Final Office Action of September 6, 2006 and 

Response to Advisory Action of December 5, 2006 

REMARKS/ARGUMENTS 

Applicants thank the Examiner Mr. Chun-Kuan (Mike) Lee and the SPE, Mr. Fritz 
Fleming, for their time in conducting an Examiner's interview, this is truly appreciated. 
Receipt of the Interview Summary, dated October 19, 2006, is acknowledged and the 
comments/remarks stated on the Continuation Page of the same have been reviewed. It is 
believed that the claims, as recited hereinabove, alleviate the issue cited in the Interview 
Summary. That is, the task files have been added to the independent claims. 

Claims 1, 4-7, 9-21, 24-26 and 28-43 remain pending and claims 2, 3, 8, 22, 23 and 
27 have been canceled without prejudice. Claims 1, 4, 5, 20, 24 and 33 have been 
amended, as recited hereinabove. 

Claims 1, 6-7, 9-14, 20-21 and 25-26 and 28-39 have been rejected under 35 
U.S.C. 103(a) as allegedly being unpatentable over Grieff et al. (US Patent No. 6,961,813) 
(hereinafter "Grieff) in view of Talati (US Patent No. 6,763,402) (hereinafter referred to 
as "Talati"). It is believed however that the foregoing claims, as recited hereinabove are 
patentable and all claims depending therefrom are patentable over Grieff in view of Talati. 

The remarks appearing in the Interview Summary of October 19, 2006, have been 
reviewed and in connection therewith, it should be noted that unlike Talati, the claimed 
invention does not require the hosts to log in. Nevertheless, host task files have been 
added to the independent claims and in this manner, in the claimed invention, the first host 
or second host units concurrently access the device, as recited hereinabove. 

More specifically, in the claimed invention, the first and second task files are each 
separately responsive to commands from the first and second host units, respectively, and 
as such they allow for "concurrently accessing the device, through the switch, by 
accepting commands, from either of the first or second host units, at any given time, 
Furthermore, arbitration is not performed until after commands have been stored in the 
task files. In contrast thereto, Talati uses a single queue, i.e. buffer RAM 194 and 
performs arbitration of commands prior to queuing, which are some of the reasons, among 
others, for preventing Talati from "accepting commands, from either host, at any given 
time". [See Talati: Col. 5, Ins. 26-30]. 

Furthermore, the combination of Grieff and Talati is believed to be erroneous as 
Talati is directed to the problem of interfacing a data storage device, a SATA device, to a 
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plurality of host data processing systems, through an IEEE 1349a bus and therefore uses 
bridges to convert the interface protocols and, whereas, Grieff is directed to a switch 
receiving input, through S ATA ports, from multiple host devices and an arbiter module for 
assigning a priority scheme to received commands and for transmission thereof to a 
storage device through SATA ports. Therefore, Talati would not have been motivated to 
solve the problem solved by the claimed invention by using the teachings of Grieff, as 
Talati did not consider receiving input from SATA ports. 

It is therefore believed that claims 1, 6-7, 9-14, 20-21 and 25-26 and 28-39 are 
patentable over Grieff in view of Talati and all claims depending therefrom are also 
necessarily patentable. 

It is believed that Ng (US Patent 6,388,590) (hereinafter referred to as "Ng") also 
lacks separate task files for each host and therefore does not render the claimed invention 
obvious in combination with the foregoing references. For example, in Fig. 3, if the PC 52 
is perceived as a host, there is only one task file 72b in the CD-ROM device 54. 
Furthermore, there is only one host and arbitration is not done after receipt of commands. 

Claims 2-5 and 22-24 have been rejected under 35 U.S.C. 103(a) as being 
unpatentable over Grieff and Talati in view of Ng (US Patent 6,388,590) (hereinafter 
referred to as "Ng"). It is believed that Ng also lacks separate task files for each host unit 
and therefore does not render the claimed invention obvious in combination with the 
foregoing references. For example, in Fig. 3, if the PC 52 is perceived as a host unit, there 
is only one task file 72b in the CD-ROM device 54. Furthermore, there is only one host. 
It is believed that the claimed invention is patentable over these references for, inter alia, 
the foregoing reasons. As a separate basis of patentability, the combination of the 
foregoing references, as the basis of rejection, is disagreed therewith since neither of these 
references suggests or hints at the teachings of the other for reasons indicated above in 
addition to others. 

It is therefore believed that claims 2-5 and 22-24 are patentable over Grieff in view 
of Talati and in further view of Ng and all claims depending therefrom are also necessarily 
patentable. 

Reconsideration and allowance of claims 1-7, 9 - 26 and 28 - 32 is hereby 
respectfully requested. Consideration and allowance of claims 33-43 is additionally 
respectfully requested. Applicants submit that the subject application is now in condition 
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for allowance and an early notice thereof is respectfully requested. Should any further 
amendment be required prior to passing the application to issue, the Examiner is 
respectfully invited to contact the undersigned by telephone at the number set out below. 



REMARKS REGARDING THE ADVISORY ACTION OF 12/5/06 

Lastly and not related to the current office action, Applicant has noticed a 
statement that warrants attention in terms of correcting the previous record. In conducting 
a review of the first Examiner's Interview Summary, which was after the first interview 
and on page 4, paragraph 5, last sentence thereof, a statement was made as to " However, 
the applicant agrees that while the device is in an idle state, commands can be received 
concurrently.", which is disagreed with but was not mentioned in the last office action 
response. The foregoing quoted comment was made regarding Grieff While Grieff is 
believed to receive concurrent requests, it cannot concurrently receive commands at any 
time including in idle state. This point is stated here merely to correct the record and 
serves no purpose as to the current rejections. 

Comments further detailing the foregoing and responding to the requests made in 
the Advisory Action of December 5, 2006 are now made. In the Advisory Action, it is 
stated that the Applicant has not clearly provided a record pertaining to the interviews. 
However, this has been done in previously amendments/responses. For example, in the 
Amendment of July 5, 2006, at page 14, Applicant stated that "The remarks appearing in 
the Interview Summary of May 31, 2006, on the continuation page, basically summarize 
the Applicants' position with one exception, which will be indicated shortly, and will 
therefore not be repeated here. As to the exception, in the third line of Paragraph 5 of the 
Continuation Page of the Interview Summary after the words " no further command can 
be received from the other host", we would add the words "until the current command is 
completed and acknowledgement thereof has been made." Similar statements were made 
in the Remarks Section of the Amendment of November 6, 2006. Accordingly, Applicant 
has clearly provided a record pertaining to the interviews. 
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Request A s To The Reason For The Disagreement With The Statement "However 
the applic ant's agrees that while the device is in an idle state, commands can be 
receive concurrently" 

With regard to the Examiner's request, in the Advisory Action, as to the reason for 
the disagreement with the statement "However the applicant's agrees that while the device 
is in an idle state, commands can be receive concurrently", again, it is believed this was 
stated in the Amendment of July 5, 2006 and is repeated herein as follows: 

"In summary, in Grieff, it is believed that, for a number of reasons, which, for the 
sake of brevity, are not enumerated here, at any given time, only one of the host ports (130 
or 132) can send commands to the drive via the dual port adaptor. More specifically, 
while a host that has won arbitration is permitted to send a command to the dual port 
adaptor, the other host is prevented from sending commands to the dual port adaptor until 
the occurrence of a particular event assignment, by the arbiter module 112, of the 
highest priority to the host that is prevented from sending commands upon completion of 
execution of the command in progress [See Grieff: Col. 5, Ins. 49-64 and col. 7, Ins. 2-6]. 
Accordingly, the dual port adaptor of Grieff receives commands sequentially. 
In contrast thereto, in an embodiment of the present invention, as shown, for example, in 
Fig. 6 of the subject application, the host ports (310, and 320) are layer 4 SATA ports 
which each include a task file for receiving commands from a host regardless of the host 
wining arbitration. Thus, the hosts are not required to win arbitration prior to sending a 
command to the switch, as required in Grieff, rather, the two hosts, through their 
respective host ports can send commands to the switch concurrently, as recited in the 
amended claimed invention. Thus, it is believed that claims 1 and 20 are patentable over 
Grieff and therefore, all claims depending therefrom are necessarily patentable over 
Grieff." 

The foregoing quotation is believed to satisfy the Examiner's request as to the 
reason for the disagreement with the statement "However the applicant's agrees that while 
the device is in an idle state, commands can be receive concurrently". Additionally, 
Grieff s disclosure, as presented, cannot support accepting commands concurrently 
because the commands are believed to be stored in Host FIS Buffer and FIS Command 
Decoderl20 [See Grieff: Col. 5, Ins. 27-28 and col. 7, Ins. 9-13], which receives only one 
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input and that is from the switch 1 10, thus, there does not appear to be any way to achieve 
concurrent acceptance of commands, at any time, even at idle times (See Grieff: Fig. 1 ,). 
For the foregoing reason(s), it is believed that, in Grieff, commands cannot be received 
concurrently even while the device is in idle state. 

Evidences That Clearly Delineate the Difference Between a "Request" and a 
"Command" 

In the context of Grieff, a "request" is not a "command" because a "request" 
appears to be an XRDY primitive, which is defined in the SATA Specification, at 
Revisionl.Oa, 7- January 2003, page 147. In Grieff, it is stated that "In an exemplary 
embodiment, the arbiter module 1 12 detects X RDY primitive from the Link Layer state 
machines of each host port 130, 132 as the requests to gain access to the device." (Grieff: 
col. 5, 11. 50-53 emphasis added). A "request", according the SATA Specification, is in 
the form of a "primitive", an example of which is the XRDY primitive, which is used by 
Grieff Evidence for support thereof can be found in the foregoing SATA Specification, at 
page 147 in the Revision 1.0a, 7- January 2003. It is stated there that X_RDY 
(Transmission data ready) primitive indicates "current node (host or device) has payload 
ready for transmission". R RDY (Receiver ready) indicates "current node (host or device) 
is ready to receive payload". To conform to the SATA Specification, a connection must 
first be established and X RDY/R RDY handshake be made before any command is sent. 

"Command", in the context of the SATA Specification, is issued to a device and is for 
performing a certain function. "The Register - Host to Device FIS is used to transfer the 
contents of the Shadow Register Block from the host to the device. This is the mechanism 
for issuing legacy ATA commands to the device" (Serial ATA Specification, page 1 87, 
sec. 8.5.2.1). This appears to be consistent with the way in which Grieff considers 
commands because in Grieff is stated that "these commands involve the initial transfer of 
the command from the host to the device via a Host-to-Device Register FIS (Grieff: col. 
7, 11. 42-44). The claimed invention is directed to "SATA", in accordance with the SATA 
Specification, hence, a "request" is not intended to be the same as a "command". 

Additionally, Grieff itself draws the distinction between a "request" and a "command" 
by its use of the two terms. For example, in Grieff, it is stated that "In an exemplary 

Siliconstor-0001 1 -i 



Application No. 10/775,488 

Amendment dated January 8, 2007 

Reply to Final Office Action of September 6, 2006 and 

Response to Advisory Action of December 5, 2006 

embodiment, the arbiter module 1 12 detects X_RDY primitive from the Link Layer state 
machines of each host port 130, 132 as the requests to gain access to the device." (Grieff: 
col. 5, 11. 50-53 emphasis added). It is also stated that "When the Command Tracker state 
machine 1 14 detects that the serial ATA device has completed execution of a command 
(ReArb), the arbiter module swaps the priorities of the requests from the Link Layer state 
machines of each host port 130, 132" (Grieff: col. 5, 11. 56-60 emphasis added). Thus, 
Greiff clearly states that a request is sent to gain access to the device and further uses 
"command" as that which is being executed and not a request. Thus, Grieff cannot be 
interpreted to teach "sending a command that requests connectivity to the peripheral", as 
suggested in the Advisory Action. 

Evidences That Clearly Show Applicant's Interpretation of Grieff Regarding "after 
receiving of concurrent requests to gain access of the device and after access have 
been granted to one of the host " 

To more clearly address this request, a response thereto has been divided into to sub- 
headings as follows: 

In Grieff only one command can be received at any given time: 

As previously noted, Grieff s disclosure cannot support accepting commands 
concurrently because the commands, in Grieff appear to be stored in the Host FIS Buffer 
and FIS Command Decoder 120, which is shown to receive only one input and that input is 
from the switch 1 10 coupling the command. Thus, there does not appear to be any way to 
achieve concurrent acceptance of commands, at any time, even at idle times by the 
disclosure of Grieff. 

Furthermore, in Grieff, because only the Host FIS Buffer & FIS Command decoder 
120 stores received commands and also apparently decodes received commands (See 
Grieff: Col. 5, Ins. 27-28 and col. 7, Ins. 9-13), it is believed that Grieff can only receive 
and detect one command at any given time. 
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In Grieff proces sing of a received command is required before another command can 
be received 

In Grieff, the state machines in Figs. 2-10 appear to offer further details of the 
Command Tracker SM 1 14 of Fig. 1 and in accordance therewith, one of ordinary skill in 
the art cannot reasonabley interpret Grieff to enable "receiving commands from the other 
host after granting of access to one of the hosts", as suggested in the Advisory Action. 
Evidence of the foregoing is disclosed in Grieff and quoted herein: "At step 1012, the link 
layer enters a loop that waits to receive an XRDY primitive. At step 1014, the link layer 
enters a loop that waits for FIS buffer to become available " (Grieff: col. 16, 11. 57-59, 
emphasis added). Therefore, since the FIS buffer, in Grieff, stores the current command 
and the current command must be processed while in the FIS buffer before the FIS buffer 
becomes available, another command cannot possibly be received, at least not according 
the disclosure of Grieff. Completion of a command is detected by the SM 1 14, as 
discussed at col. 6, Ins. 16-26 in Grieff. Furthermore, in Grieff, only after a command has 
been completed, can a new arbitration cycle begin (See Grieff: col. 7, Ins 2-6). 

In the Advisory Action, it is stated that "one of ordinary skill in the art, in viewing 
Grieff s Fig. 1 , may interpret that there appears to have more than one interconnection 
between the hosts and the peripheral, such as the two other interconnection right next to 
the multiplexer that directly connects the arbiter unit to the Command Tracker SM that 
may enable the carrying of data between the hosts and the peripheral, therefore ..." 
However, the signals shown to the right of the switch 110 that are shown between 
Command Tracker SM 1 14 and Arbiter 1 12 do not couple or carry command. These 
signals are: ReArb, ForceArb Winner, HostSelect, D2H_Xrdy, Force_D_R_ERR (shown 
going out of the SM 1 14 to Arbiter 1 12) and Arb Winner, (shown coming from Arbiter 1 12 
to the SM 1 14). These signals appear to be signaling or indicative of an event, they are 
not, however, commands. 

For example, the ReArb is used to "inform the arbitration logic that a command 
has just completed and that a new arbitration cycle can begin" (Grieff col. 7, 11.4-6), the 
ForceArbWinner, HostSelect: signals are used to "indicate which Host the arbitration 
logic should allow a connection to the device" (Grieff col. 6, Ins. 41-42), the signal 
D2H_Xrdy is an output from Command Tracker state machine in transition from state 
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AwaitDataFIS_DI to state FwdDataFIS_DI (See Grieff Fig. 4), the signal Forec_D_R_Err 
is an output from Command Tracker state machine in transition from state Linkldle to 
state AwaitHostSYNC (See Grieff Fig. 2), and the ArbWinner signal "The Host that sent 
the command is determined from the ArbWinner signal from the arbitration block. (Grieff 
col. 10, IL 49-50). 

Therefore, it is believed that a person of ordinary skill in the art, cannot justifiably 
use these signals to interpret "enabling carrying of data between the hosts and the 
peripheral" nor can these signals be interpreted to be carrying or coupling commands. 

It is believed that all requests made in the Advisory Action have been responded 
thereto, hereinabove, however, in the event there are further requests, the Examiner is 
invited to contact the undersigned. Again, Applicant wishes to thank the Examiner and his 
supervisor for conducting interviews. 



I hereby certify that this correspondence with all attachments is being deposited with the U.S. Postal Service as first class mail in an 
envelope addressed to: Mail Stop RCE, Commissioner for Patents, P.O. Box 1450, Alexandria VA 22313-1450 on January 8, 2007 by 
Carmen Aviles. 



Respectfully submitted, 
LAW OFFICES OF IMAM 



Dated: January 8. 2007 

LAW OFFICES OF IMAM 

1 1 1 North Market Street, Suite 1010 
San Jose, C A 95113 
Tel: 408-271-8752 




Maryam Imam 
Reg. No. 38,190 
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